home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 3⁄30⁄90 / 1005-RE(2) FindObject() a-Mar90 < prev    next >
Encoding:
Text File  |  1990-03-30  |  2.4 KB  |  56 lines  |  [TEXT/GEOL]
  1. Item    8319507                         29-March-90        20:58PST
  2.  
  3. From:   MADA2                           MacApp Dev Assoc, Curtis Faith,IVC
  4.  
  5. To:     POWERUP.DEV                     Power Up Software,PRT
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    RE(2) FindObject() and FindVa
  10.  
  11. James,
  12.  
  13. To reaffirm Jeff's statement I too think that one should be able to pass a
  14. method just like one can now pass a local procedure.  This comes up quite often
  15. and is a much more general problem.
  16.  
  17. Your FindObject proposal appears useful (in fact I have done the same thing
  18. once or twice). It requires no additional OVERRIDE's since one would have had
  19. to OVERRIDE Compare anyway, and it is a logical extension to GetEqualItemNo.
  20. Though, I would call it GetEqualObject to be more consistent with
  21. GetEqualItemNo and to make it obvious that it is not necessarily the same as
  22. the object you pass in as a parameter.
  23.  
  24. You state that "I keep having to include the #$!@% TestItem() function in my
  25. code, as a local function to the routine that calls search().  This wastes my
  26. time, clutters my code, and increases the change of error - specifically, that
  27. the various versions of TestItem() won't match."
  28.  
  29. I gather from the above that you often use a particular identical (at least you
  30. hope) TestItem as a local procedure parameter to a bunch of Search calls in
  31. various parts of your application.
  32.  
  33. Perhaps I am missing something but:
  34.  
  35. Why could you not simply subclass TSortedList and provide a new method
  36. TMySortedList.FindSomeObjectThatIWant that uses the particular TestItem
  37. mentioned above.  You would use FindSomeObjectThatIWant instead of
  38. Search(TestItem).  You would have only one instance of TestItem to worry about
  39. and your code would be more readable since you could name the method in a way
  40. that lends meaning (FindOldestObject, FindBiggestObject, etc.).
  41.  
  42. I fail to see any advantage to FindValue as a generic routine.  Why not
  43. encapsulate all the finding into another method that you call something else as
  44. I describe above?   FindValue also limits a particular object to having only
  45. one search criterion unless one bypasses it and uses Search directly.  Having
  46. one search done via an OVERRIDE to CompareValue and one or more via calls to
  47. Search directly would be really confusing.
  48.  
  49. With your proposed solution you still have to OVERRIDE so I don't really see
  50. where anything is gained, and I for one find the current scheme confusing
  51. enough already.
  52.  
  53. - Curtis
  54.  
  55.  
  56.